This is very interesting. I had this test failing initially as well. I reran it and then it worked. So there might be ambiguity in the ordering because of the changes from my pr. Is the order of any importance. Otherwise a set instead of the array would make more sense anywyas and we don't need to enforce the order somehow artificially.

Just to get right what is happening here.
We use the age to order the events? Before the age was just 0 because that is the fallback if the unsigned field is missing. Now we use now - origin server , which is a better approximation for the age then 0. So the code execution order plays a role since sometimes one Ms passes and then they don't have the same age anymore?
The timeline orders by age?

Maybe mocking the age explicitly (in general for the mockEvent fn) would be a cleaner solution then?

But changing the origin_server_ts is a good fix as well.

I ran the failing jest test again and it passed so we have a flake

Is the order of any importance. Otherwise a set instead of the array would make more sense anywyas and we don't need to enforce the order somehow artificially.

what about this?

I ran the failing jest test again and it passed so we have a flake.

I think this is coming from the age now beeing dependent on Date.now(). (is th age used for timeline ordering?)

I think the order does matter since I expect the events to be ordered in a very specific way when two timelines are merged.
The localTimeStamp property of the event is used for ordering events in this case. I've set them explicitly so it should be okay now.

I created a draft PR: matrix-org/matrix-js-sdk#3854
How about we merge this one first, and then we can see if the CI is still flaky for matrix-org/matrix-js-sdk#3854?
Then we can then savely merge the fix that for the event age somtimes beeing 0 (which breaks expiration logic for calls)